<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic id="topic_nyc_mdf_jr">
  <title>Security Best Practices</title>
  <shortdesc>Describes basic security best practices that you should follow to ensure the highest
    level of system security. </shortdesc>
  <body>
    <p>In the default Greenplum Database security configuration:<ul id="ul_mhk_rrg_4r">
        <li>Only local connections are allowed. </li>
        <li>Basic authentication is configured for the superuser (<codeph>gpadmin</codeph>).</li>
        <li>The superuser is authorized to do anything.</li>
        <li>Only database role passwords are encrypted.</li>
      </ul></p>
    <section>
      <title>System User (gpadmin)</title>
      <p>Secure and limit access to the <codeph>gpadmin</codeph> system user. </p>
      <p>Greenplum requires a UNIX user id to install and initialize the Greenplum Database system.
        This system user is referred to as <codeph>gpadmin</codeph> in the Greenplum documentation.
        The <codeph>gpadmin</codeph> user is the default database superuser in Greenplum Database,
        as well as the file system owner of the Greenplum installation and its underlying data
        files. The default administrator account is fundamental to the design of Greenplum Database.
        The system cannot run without it, and there is no way to limit the access of the
          <codeph>gpadmin</codeph> user id. </p>
      <p>The <codeph>gpadmin</codeph> user can bypass all security features of Greenplum Database.
        Anyone who logs on to a Greenplum host with this user id can read, alter, or delete any
        data, including system catalog data and database access rights. Therefore, it is very
        important to secure the <codeph>gpadmin</codeph> user id and only allow essential system
        administrators access to it. </p>
      <p>Administrators should only log in to Greenplum as <codeph>gpadmin</codeph> when performing
        certain system maintenance tasks (such as upgrade or expansion). </p>
      <p>Database users should never log on as <codeph>gpadmin</codeph>, and ETL or production
        workloads should never run as <codeph>gpadmin</codeph>. </p>
    </section>
    <section>
      <title>Superusers</title>
      <p>Roles granted the <codeph>SUPERUSER</codeph> attribute are superusers. Superusers bypass
        all access privilege checks and resource queues. Only system administrators should be given
        superuser rights. </p>
      <p> See "Altering Role Attributes" in the <i>Greenplum Database Administrator Guide</i>. </p>
    </section>
    <section>
      <title>Login Users</title>
      <p>Assign a distinct role to each user who logs in and set the <codeph>LOGIN</codeph>
        attribute. </p>
      <p>For logging and auditing purposes, each user who is allowed to log in to Greenplum Database
        should be given their own database role. For applications or web services, consider creating
        a distinct role for each application or service. See "Creating New Roles (Users)" in the
          <i>Greenplum Database Administrator Guide</i>. </p>
      <p>Each login role should be assigned to a single, non-default resource queue.</p>
    </section>
    <section>
      <title>Groups</title>
      <p>Use groups to manage access privileges.</p>
      <p>Create a group for each logical grouping of object/access permissions. </p>
      <p>Every login user should belong to one or more roles. Use the <codeph>GRANT</codeph>
        statement to add group access to a role. Use the <codeph>REVOKE</codeph> statement to remove
        group access from a role. </p>
      <p>The <codeph>LOGIN</codeph> attribute should not be set for group roles. </p>
      <p>See "Creating Groups (Role Membership)" in the <i>Greenplum Database Administrator
          Guide</i>. </p>
    </section>
    <section>
      <title>Object Privileges</title>
      <p>Only the owner and superusers have full permissions to new objects. Permission must be
        granted to allow other rules (users or groups) to access objects. Each type of database
        object has different privileges that may be granted. Use the <codeph>GRANT</codeph>
        statement to add a permission to a role and the <codeph>REVOKE</codeph> statement to remove
        the permission.</p>
      <p>You can change the owner of an object using the <codeph>REASSIGN OWNED BY</codeph>
        statement. For example, to prepare to drop a role, change the owner of the objects that
        belong to the role. Use the <codeph>DROP OWNED BY</codeph> to drop objects, including
        dependent objects, that are owned by a role.</p>
      <p>Schemas can be used to enforce an additional layer of object permissions checking, but
        schema permissions do not override object privileges set on objects contained within the
        schema.</p>
    </section>
    <section id="password-strength-recommendations">
      <title>Operating System Users and File System</title>
      <p>
        <note>Commands shown in this section should be run as the root user.</note>
      </p>
      <p>To protect the network from intrusion, system administrators should verify the passwords
        used within an organization are sufficiently strong. The following recommendations can
        strengthen a password: </p>
      <ul>
        <li> Minimum password length recommendation: At least 9 characters. MD5 passwords should be
          15 characters or longer. </li>
        <li> Mix upper and lower case letters. </li>
        <li> Mix letters and numbers. </li>
        <li> Include non-alphanumeric characters. </li>
        <li> Pick a password you can remember. </li>
      </ul>
      <p> The following are recommendations for password cracker software that you can use to
        determine the strength of a password. </p>
      <ul id="ul_gd3_fxg_4r">
        <li> John The Ripper. A fast and flexible password cracking program. It allows the use of
          multiple word lists and is capable of brute-force password cracking. It is available
          online at <xref href="http://www.openwall.com/john/" format="html" scope="external"
            >http://www.openwall.com/john/</xref>. </li>
        <li>Crack. Perhaps the most well-known password cracking software, Crack is also very fast,
          though not as easy to use as John The Ripper. It can be found online at <xref
            href="https://dropsafe.crypticide.com/alecm/software/crack/c50-faq.html" format="html"
            scope="external"
            >https://dropsafe.crypticide.com/alecm/software/crack/c50-faq.html</xref>.  </li>
      </ul>
      <p>The security of the entire system depends on the strength of the root password. This
        password should be at least 12 characters long and include a mix of capitalized letters,
        lowercase letters, special characters, and numbers. It should not be based on any dictionary
        word. </p>
      <p> Password expiration parameters should be configured. The following commands must be run as
          <codeph>root</codeph> or using <codeph>sudo</codeph>.</p>
      <p> Ensure the following line exists within the file <codeph>/etc/libuser.conf</codeph> under
        the <codeph>[import]</codeph> section. </p>
      <codeblock>login_defs = /etc/login.defs
</codeblock>
      <p> Ensure no lines in the <codeph>[userdefaults]</codeph> section begin with the following
        text, as these words override settings from <codeph>/etc/login.defs</codeph>: </p>
      <ul id="ul_ef3_fxg_4r">
        <li>
          <codeph>LU_SHADOWMAX</codeph>
        </li>
        <li>
          <codeph>LU_SHADOWMIN</codeph>
        </li>
        <li>
          <codeph>LU_SHADOWWARNING</codeph>
        </li>
      </ul>
      <p> Ensure the following command produces no output. Any accounts listed by running this
        command should be locked. </p>
      <codeblock>
grep &quot;^+:&quot; /etc/passwd /etc/shadow /etc/group
</codeblock>
      <p> Note: We strongly recommend that customers change their passwords after initial setup. </p>
      <codeblock>
cd /etc
chown root:root passwd shadow group gshadow
chmod 644 passwd group
chmod 400 shadow gshadow
</codeblock>
      <p> Find all the files that are world-writable and that do not have their sticky bits set. </p>
      <codeblock>
find / -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print
</codeblock>
      <p> Set the sticky bit (<codeph># chmod +t {dir}</codeph>) for all the directories that result
        from running the previous command. </p>
      <p> Find all the files that are world-writable and fix each file listed. </p>
      <codeblock>
find / -xdev -type f -perm -0002 -print
</codeblock>
      <p> Set the right permissions (<codeph># chmod o-w {file}</codeph>) for all the files
        generated by running the aforementioned command. </p>
      <p> Find all the files that do not belong to a valid user or group and either assign an owner
        or remove the file, as appropriate. </p>
      <codeblock>
find / -xdev \( -nouser -o -nogroup \) -print
</codeblock>
      <p> Find all the directories that are world-writable and ensure they are owned by either root
        or a system account (assuming only system accounts have a User ID lower than 500). If the
        command generates any output, verify the assignment is correct or reassign it to root. </p>
      <codeblock>
find / -xdev -type d -perm -0002 -uid +500 -print
</codeblock>
      <p> Authentication settings such as password quality, password expiration policy, password
        reuse, password retry attempts, and more can be configured using the Pluggable
        Authentication Modules (PAM) framework. PAM looks in the directory
          <codeph>/etc/pam.d</codeph> for application-specific configuration information. Running
          <codeph>authconfig</codeph> or <codeph>system-config-authentication</codeph> will re-write
        the PAM configuration files, destroying any manually made changes and replacing them with
        system defaults. </p>
      <p> The default <codeph>pam_cracklib</codeph> PAM module provides strength checking for
        passwords. To configure <codeph>pam_cracklib</codeph> to require at least one uppercase
        character, lowercase character, digit, and special character, as recommended by the U.S.
        Department of Defense guidelines, edit the file <codeph>/etc/pam.d/system-auth</codeph> to
        include the following parameters in the line corresponding to password requisite
          <codeph>pam_cracklib.so try_first_pass</codeph>. </p>
      <codeblock>retry=3:
dcredit=-1. Require at least one digit
ucredit=-1. Require at least one upper case character
ocredit=-1. Require at least one special character
lcredit=-1. Require at least one lower case character
minlen-14. Require a minimum password length of 14.</codeblock>
      <p> For example: </p>
      <codeblock>
password required pam_cracklib.so try_first_pass retry=3\minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1
</codeblock>
      <p> These parameters can be set to reflect your security policy requirements. Note that the
        password restrictions are not applicable to the root password. </p>
      <p> The <codeph>pam_tally2</codeph> PAM module provides the capability to lock out user
        accounts after a specified number of failed login attempts. To enforce password lockout,
        edit the file <codeph>/etc/pam.d/system-auth</codeph> to include the following lines:<ul
          id="ul_ehw_ls2_lr">
          <li>The first of the auth lines should
            include:<codeblock>auth required pam_tally2.so deny=5 onerr=fail unlock_time=900</codeblock></li>
          <li>The first of the account lines should
            include:<codeblock>account required pam_tally2.so</codeblock></li>
        </ul></p>
      <p>Here, the deny parameter is set to limit the number of retries to 5 and the
          <codeph>unlock_time</codeph> has been set to 900 seconds to keep the account locked for
        900 seconds before it is unlocked. These parameters may be configured appropriately to
        reflect your security policy requirements. A locked account can be manually unlocked using
        the <codeph>pam_tally2</codeph>
        utility:<codeblock>
/sbin/pam_tally2 --user {username} --reset
</codeblock></p>
      <p> You can use PAM to limit the reuse of recent passwords. The remember option for the
          <codeph>pam_ unix</codeph> module can be set to remember the recent passwords and prevent
        their reuse. To accomplish this, edit the appropriate line in
          <codeph>/etc/pam.d/system-auth</codeph> to include the remember option. </p>
      <p> For example: </p>
      <codeblock>
password sufficient pam_unix.so [ … existing_options …] 
remember=5
</codeblock>
      <p> You can set the number of previous passwords to remember to appropriately reflect your
        security policy requirements. </p>
      <codeblock>
cd /etc
chown root:root passwd shadow group gshadow
chmod 644 passwd group
chmod 400 shadow gshadow
</codeblock>
    </section>
  </body>
</topic>
